J'ai très peur de cette jointure qui, associée à d'autres, va faire exploser le nombre de lignes.
Mieux vaut faire une requête séparée sur les offres collectives.
Tu peux aussi ajouter des load_only sur CollectiveOffer et EducationalInstitution pour ne rapatrier de la base de données que les colonnes utiles.

Mais je pense même que plutôt que rapatrier toutes les offres, tu pourrais faire la déduction de has_collective_offers_marseille_en_grand directement côté postgresql, qui serait quelque chose comme :

select exists(
    select 1
    from collective_offer
    join educational_institution on educational_institution.id = collective_offer."institutionId"
    join educational_institution_program_association on educational_institution_program_association."institutionId" = educational_institution.id
    join educational_institution_program on educational_institution_program.id = educational_institution_program_association."programId"
    where collective_offer."venueId" = ...
    and educational_institution_program.name = 'marseille_en_grand'
    limit 1
);

ce qui a le mérite de ne demander à la base de données que true ou false plutôt que demander toutes les données uniquement dans ce but, et faire le calcul en Python.

Je me pose également une question en plus : ne veut-on pas avoir eac_meg à True uniquement si des réservations ont été faites par les établissements pendant une période du programme ? En ignorant des réservations antérieures ?

J'ai intégré cela dans une methode dédié (cf dernier commit).

Pour ta question sur la période du programme : cela n'a pas été demandé.

Un is ou has dans le nom de l'attribut serait plus cohérent avec le nommage des autres booléens.

Ok

La requête en plus vient semble-t-il des subqueryload de ta requête (j'ai testé sur ta branche, plus besoin de ce changement en remplaçant les subqueryload par des joinedload).
Mais comme je parle de revoir la requête plus haut, ça changera probablement ce qu'ont teste ici.

Je ne vois aucun test qui vérifie la valeur collectée de l'attribut eac_meg, il serait utile de vérifier que la logique est bonne, qu'elle soit exécutée en Python ou par postgreSQL.

C'est vrai, je vais intégrer cela

Détail : le and_ n'est pas nécessaire car les arguments de filter sont associés en AND.

Attention ici, tu utilises has_collective_offers qui est calculé en recherchant par adresse email de compte pro, comme condition alors que tu calcules has_collective_offers_marseille_en_grand à partir des lieux collectés en recherchant par venue.bookingEmail. Je crains qu'on puisse se retrouver avec des incohérences, car has_collective_offers sera False si l'email est utilisé uniquement dans venue.

En intuition rapide, je me dis que la condition pour faire la requête pourrait être sur quelque chose comme any(venue.adageId for venue in venues).

Je te laisse vérifier.

En fait le critère any(venue.adageId for venue in venues) n'est pas suffisant => il peut y avoir un lieux qui réaliser des projets collectif (pour marseille en grand) en dehors de l'établissement scolaire. Il faut donc a minima faire une première requete pour savoir si les lieux en questions ont été utilisé pour des offres collectives.

Puisqu'on doit faire une requête dans tous les cas. Je propose de supprimé la condition.

Je ne comprends pas bien : si le lieu n'a pas d'adageId, alors il ne peut pas proposer d'offre collective, donc n'aura jamais une offre reliée à un établissement scolaire relié lui-même au programme MEG. Mais il me manque peut-être des infos métier, qu'ai-je loupé ?

tu as raison -> il y a forcément un lieu de rattachement. Ne pas tenir compte de ma remarque précédente.

Attention par contre sur le nommage de l'attribut Brevo, car le marketing a déjà créé un attribut EAC_MEG, donc il faudra "tomber en face".
Référence : https://my.brevo.com/lists/add-attributes

je pensais en profiter pour créé un nouvel attribut (ce qui permettrait de ne pas effacer le travail de Lin).

Ok pas de souci, il faut juste prévenir le marketing pro.

Ce test est pertinent mais n'est pas suffisant pour vérifier que la fonction ici testée est appelée quand il faut. Cf. mon commentaire plus haut. Je pensais à un test dans external_pro_test.py, par exemple avec deux lieux dont le bookingEmail correpond à l'email, dont un avec une offre MEG, mais aucun compte pro n'ayant cet email.

Tu as raison, mon push d'hier soir avec ce test n'est pas passé...

Queston : Pourquoi ne pas garder uniquement les ID des lieux avec adageId ?
Quoique...tout d’un coup j’ai un doute : un vague souvenir qu’un lieu peut créer une offre collective si n’importe quel lieu de la même structure a un adageId. Ça remettrait en cause ce que je disais avant, mais je n’y pense que maintenant.

Du coup tu préconises de faire l'appel en base has_collective_offers_for_program_and_venue_ids("marseille_en_grand", venue_ids) dans tous les cas de figure ? Est-ce que cela ne va pas avoir un coup trop important pour un scénario très marginal (il me semble) ?

Je ne suis pas certain du scénario, ni qu'il soit si marginal.
Mais on doit pouvoir faire une recherche dans la base de données pour voir l'ampleur des offres collectives créées sur des lieux sans adageId.
Je ne maîtrise pas suffisamment toutes les règles métier EAC.